Your task, model a database that represents a suburban block.  You survey the area, and see the following houses (pictures culled from Wikipedia here)

and

So you look at the houses, start modeling roofs, windows, lawn, driveway, mail boxes, porches, etc etc. You get done, and with your 30+ tables you are feeling great, right? I know I would be. “I knocked this out of the park! We can capture everything about these houses.  I…am…a…superhero database modeler,” I think, “I will get a big promotion or a raise for sure! Shoot, I will get both!”

So you show this model to the client and they say, “you’re fired. Do you even know what business we are in?” Well, no, I suppose not.  That is the lesson for the day.  Perspective.  Unless you realize the perspective of the client, understand the problems they want to solve, you are missing the point.

One of my “mind exercises” I play when travelling in a car, or at a theme park, or at a doctor’s office, etc is to think about how I could make the place better with database technology. During my family’s excessive trips to Disney World, when I am the slightest bit mentally bored I think about how I could fix things. (RFID in every ticket tracking and predicting next moves, stored in a database for reevaluating how to herd people like the lunch crowd at Tech Ed, for example.)  But driving through a neighborhood the other day, it really hit me.  There are many different ways to look at a block of houses, apartments, flats, etc and model them for usage (in addition to basic locator information like address and perhaps longitude/latitude).

• Fire Department – hydrant to home to occupant ratio
• Sales – Number of windows, roof style, lawn, age of home
• Law Enforcement – Name of occupants, previous law enforcement “contact”
• Sanitation Department – Number of trash cans (including serial number for tracking), average amount of trash

And so on, but then I thought, what about the Sanitation Department. Take a side loading trash truck (http://vehiclestoys.guidestobuy.com/mack-granite-side-loading-garbage-truck):

`

What if they weighed the trash as the loaded it, then kept records of how they weight varied. They could predict how much trash they could pick up and change routes accordingly. How else might this information be used? The information might also be interesting to law enforcement. This single family dwelling makes 80% more trash that all of their neighbors.  Is this suspicious? Does it hurt to check it out? Is this getting too big brother? Maybe, depending on how the information was used, but it certainly might be used as evidence in addition to an actual complaint.

Privacy concerns aside (not that you have any privacy in your trash, right?) It will be centuries before two government organizations work together that smoothly. It can take 2 change of address forms per government agency to move from one house to another.

In the end of this technically rather soft blog, the point is that requirements govern the design. Unless you know why the user wants you to model something, you cannot do a good job of building a database to meet their needs.  Sure you can build a cool database that stores everything that you can possibly ever desire about a subject, but does it meet the needs of the user? The only way to know the needs of the user is to study them, understand them, and put yourself in their shoes. Figure out their job and build from there. Adding a few extra bells and whistles to delight the user isn’t horrible sometimes, but missing the point is.